The present invention relates to networks used in vehicles to provide distributed control of various vehicle functions and, more particularly, to such networks which utilize different groupings of electronic control units (ECUs) to carry out different control tasks.
In contemporary vehicles, electronic control units (ECUs) are distributed throughout the vehicle to perform a variety of different vehicle functions. These vehicle functions can be operator-controlled or automated and are referred to herein generally as control tasks. These control tasks can include, for example, controlling vehicle door locks, seat position, cruise control, entertainment system devices (tuners, CD players, etc.), HVAC, intrusion alarms, interior and exterior lighting, electric window position, engine and vehicle system diagnostics, and, more recently, tasks such as seat heating and reverse sensing.
A common misconception is that each of the ECUs used in the vehicle is dedicated to a specific task. While some ECUs, including powertrain control modules and anti-lock brake system controllers, tend to be dedicated to a single control task, this is generally not the case for most other ECUs. Many control tasks are performed by several ECUs working in unison and coordinating their operation via a data link. A typical ECU may contain a portion of the control logic for several unrelated vehicle control tasks, and may not contain the complete control logic for any single control task.
The ECUs are typically connected together via one or more vehicle buses, which are generally implemented as serial communication buses in the form of a local area network. In addition to the basic mechanisms for transferring signals between ECUs over the vehicle bus, any reliable communication strategy must also ensure that a number of other ancillary tasks are performed. One of these tasks is called network management and is used to provide a system-wide common approach to handling such things as: orderly start up (activation) of communication capabilities; orderly shut down (deactivation) of communication capabilities; and predictable recovery from detectable communication errors.
Mechanisms to perform orderly start up and shut down are important so that ECUs can synchronize their signal reception expectations with the other ECUs signal transmission availability. If this synchronization does not occur, an ECU may interpret the lack of signal transmissions as the failure of one of the other ECUs and adopt safe default signal values that may be perceived by the occupant as improper vehicle operation. For example, headlights may default xe2x80x9conxe2x80x9d if the day/night sensor signal is not transmitted in a timely manner.
Existing vehicle network management strategies are relatively simple. This simplicity stems from the fact that all ECUs in a vehicle are activated and deactivated simultaneously. As a result, the only complicating factor is that some ECUs may activate slower than others. There exists vehicle network schemes which permit an ECU to activate other ECUs, but not in a manner that is independent of vehicle platform and that allows multiple ECUs to activate the same collection of ECUs. Furthermore, they are not as responsive in the manner in which they perform their xe2x80x9con-demandxe2x80x9d start-up operations. This severely reduces their effectiveness because the start-up process must be done quickly enough to keep the occupant from detecting delays following a button press that requires the ECUs to perform control operations. If this cannot be done, then the only other option is to keep the ECUs awake any time that an occupant may want to use their functionality.
The electrical power consumption in contemporary vehicles is approaching the limits for what can be economically provided by the existing vehicle electrical infrastructure. One method for reducing the consumption is to place ECUs that are not actively controlling vehicle functionality into a low power xe2x80x9cstandbyxe2x80x9d, or xe2x80x9csleepxe2x80x9d state. For example, window and seat control ECUs are used infrequently and can usually be placed in standby. From a network management perspective, vehicle systems with ECUs in standby introduce considerable complexity. In these systems, it is desirable to synchronize start up and shut down of arbitrary subsets of the vehicle""s ECU population while letting other ECUs xe2x80x9csleepxe2x80x9d. Furthermore, a robust network design should be able to start ECU sets on demand without disrupting the control operations being performed by the ECUs which are already awake. Lastly, in order for an ECU to be used in multiple vehicle platforms, the ECU should be able to start up its signal providers even though the signals may be provided by different ECUs on each platform.
It is therefore a general object of this invention to provide an on-board vehicle network which utilizes a network management strategy that permits distributed ECUs on the network to activate other ECUs in a platform-independent manner using a common communication strategy which permits the ECUs to be maintained in a low power quiescent mode until needed.
The present invention provides an on-board vehicle network and method for operating the network which permits an ECU to activate the other ECUs used for a particular vehicle control task without having to know in advance what ECUs are utilized in performing the control task. The network comprises a plurality of on-board vehicle electronic control units (ECUs) connected together via at least one network bus, with the network being arranged into a plurality of virtual networks that each comprise a group of the ECUs that together perform a vehicle control task. Thus, the ECUs that together comprise a first one of the virtual networks are operable together to perform a first control task and are each identified using a first code that is associated with the first virtual network. Similarly, the ECUs that comprise the second virtual network are operable together to perform a second control task and are each identified using a second code that is associated with the second virtual network. The first and second virtual networks can be activated using respective first and second messages that they receive over the vehicle bus. Once activated a virtual network is then operable to perform its associated control task. Preferably, the messages include one or more of the codes used to identify the ECUs in a particular virtual network. In this way, an ECU can wake-up other ECUs out of their standby mode without having to know which ECUs are a part of the virtual network used to implement a particular control task.
In accordance with another aspect of the invention, there is provided a method of managing an on-board vehicle network that utilize ECUs that can be switched between and active state and a low power quiescent state. The network includes at least one group or subset of the ECUs on the network, with the group of ECUs being operable together to perform a particular vehicle control task. The method includes the steps of: receiving a signal request for activating a control task; waking up the ECUs out of the low power quiescent state; and sending a message to the ECUs that includes a code associated with the control task. This message is received by some or all of the ECUs in the network and, for each of these ECUs, if the code included with the message corresponds to a control task associated with the ECU, then the ECU enters into an active state in which the ECU is operable to perform the control task together with other ECUs associated with the control task. However, if the code included with the message does not correspond to a control task associated with the ECU, then it enters into the low power quiescent state.
If necessary, the messages to the ECUs can be preceded by a wake-up signal which switches all of the quiescent ECUs to the active state. Once the ECUs are awakened, they each monitor the network for receipt of a message containing a code associated with one of the control tasks for which they are used. If no code is received within a period of time following the wake-up signal, they switch back to their low power quiescent state. If a code is received, then each ECU checks to see whether it is associated with the received code; if so, it enters into a program mode in which it operates with the other appropriate ECUs to carry out the associated control task. If not, the ECU switches back to the quiescent state. In this way, any ECU on the network can be used to activate other ECUs associated with a particular control task, and can do so without having to know which or how many other ECUs are involved. This permits system designs in which a particular ECU can be used on different vehicle platforms, even if the function is performed differently on each platform.